Commitment Agreement
En esta página se recoge el feedback proporcionado por el profesor y los compañeros relativo al Commitment Agreement en las presentaciones realizadas por los grupos durante las sesiones de clase. El objetivo principal es identificar los puntos fuertes y aspectos a mejorar con el fin de aprender de los errores y mejorar para el futuro.
Feedback del día 14/02
-
Desde el inicio del proyecto, se destacó la necesidad de un acuerdo de compromiso (Commitment Agreement) para garantizar la responsabilidad y participación equitativa del equipo.
-
Se establecieron las siguientes bases:
- Definir claramente los roles y responsabilidades de cada miembro.
- Asegurar un compromiso real con el trabajo del equipo, evitando la falta de contribución.
- Plantear una estrategia de seguimiento del cumplimiento de tareas semanales.
-
En esta etapa inicial, se hizo énfasis en que todos los miembros deben contribuir activamente, evitando que la carga recaiga en unos pocos.
Feedback del día 21/02
-
El Commitment Agreement evolucionó en la segunda semana con la incorporación de mecanismos de seguimiento y penalización. Se planteó la necesidad de establecer un sistema claro de strikes o penalizaciones, pero con una lógica bien definida:
-
Explicar qué significa un strike y sus consecuencias (por ejemplo, reducción de responsabilidades o advertencias formales).
-
Definir un sistema de recompensas y sanciones para equilibrar la motivación del equipo.
-
Asegurar que todos los miembros desarrollen y no solo pertenezcan a roles administrativos.
-
Además, se insistió en la planificación detallada de los sprints, estableciendo una metodología de trabajo que asegure el cumplimiento de los objetivos semanales.
Feedback del día 07/03
-
El seguimiento del Commitment Agreement en esta fase se enfocó en asegurar el equilibrio de trabajo entre los miembros del equipo y la correcta medición del rendimiento.
-
Principales mejoras y observaciones:
- Revisión de métricas cuantitativas, obteniendo datos concretos sobre el desempeño individual y grupal, sin fomentar prácticas artificiales como el aumento innecesario de commits.
- Distribución equitativa de tareas, asegurando que todos los miembros contribuyan de manera balanceada y no se concentren únicamente en roles administrativos.
- Estrategia de penalización y recompensa, consolidando el sistema de seguimiento de compromisos para evitar la sobrecarga de algunos integrantes.
- Retroalimentación en presentaciones, asegurando que los avances reflejen realmente el esfuerzo del equipo y no solo la asignación de tareas.
-
Se hizo especial énfasis en que el Compromiso del equipo debe verse reflejado en la documentación y presentaciones, destacando puntos clave y asegurando una estructura clara que comunique avances reales.
Feedback del día 14/03
-
En el feedback de la Semana 6, se destacó la importancia de registrar y comunicar con claridad los motivos por los cuales un miembro no ha podido contribuir al proyecto. Expresiones ambiguas como "por motivos varios" deben evitarse, ya que no proporcionan información útil para la gestión del equipo. En su lugar, se recomienda indicar "por motivos personales de distinta índole", lo que cierra la explicación de forma más concreta sin ser invasivo.
-
Otro punto relevante es la planificación y la forma en que se presentan los avances. Se enfatizó la necesidad de no dividir una tabla en dos diapositivas y de evitar explicar demasiado una parte mientras se omite la otra. Esto refleja la importancia de un compromiso equitativo en la exposición de la información, asegurando que cada aspecto del proyecto reciba la atención necesaria.
-
Además, en la evaluación individual y de equipo, se mencionó la importancia de explicar cómo las métricas de productividad afectan la valoración del trabajo realizado. Esto implica que el compromiso de cada miembro debe ser medido y visible, de manera que todos comprendan su impacto en el proyecto y puedan ajustar su rendimiento en función del análisis proporcionado.
Feedback del día 21/03
- Comentar explícitamente si ha habido algún miembro que no ha cumplido con las expectativas, compromisos no cumplidos del CA, qué medidas se han tomado y si estas han servido para solventar el problema.
Feedback del día 28/03
- Posibilidad de poner algo relacionado a la propiedad intelectual.
- Diferenciación de terminos de uso y sistema de pagos.
- Tratar el GDPR.
- Incidir en la política de cancelación.
- Hablar de cookies, SLA y licencias.
Feedback del día 04/04
El feedback hizo una llamada implícita a la responsabilidad individual dentro del equipo. Se subrayó que no todos los errores técnicos deben recaer en el usuario piloto y que algunos de los problemas detectados reflejan una falta de control interno más que una validación externa. Esta observación apunta a la necesidad de reforzar el compromiso interno: mantener una cultura de calidad, definir bien los roles y, si es necesario, ajustar el tipo de tareas de algunos miembros para facilitar su implicación. Además, se valoró positivamente la propuesta de designar supervisores dentro del equipo que puedan acompañar a quienes están menos activos, una práctica que fortalece la cohesión grupal.
Feedback del día 11/05
- Documento que define cómo se organiza el equipo fundador.
- Aclara roles, porcentaje de participación, dedicación y reglas ante posibles conflictos.
- Es vital para evitar malentendidos futuros.
Feedback del día 25/05
- Poco desarrollado en la mayoría de los grupos.
- Roles mal definidos en vídeos de inversores.
- Se sugiere ser más claro con las cifras ofrecidas a cambio de inversión.
- Dejar muy claro quién hace qué y las normas establecidad.
Feedback del día 02/05
Se remarca nuevamente que justificar los proyectos por el esfuerzo o la cantidad de trabajo invertido no es relevante para los resultados; lo importante es mostrar progreso y resultados tangibles. Hubo énfasis en que las exposiciones reflejen concretamente un compromiso claro y sólido por parte de todo el equipo, usando términos profesionales y evitando detalles excesivos sobre la estructura interna del grupo (por ejemplo, utilizar “equipo de desarrollo” en lugar de detallar nombres y roles). También se insiste en evaluar objetivamente el rendimiento del grupo y aprender de los problemas que hayan surgido durante el proceso.